System and method for process migration in a content centric network

ABSTRACT

One embodiment provides a system that facilitates a migration of a data model from a source device to a target device. During operation, the system generates, by a target device, a first interest for a first manifest which represents a version of the data model, wherein a manifest indicates a phase of the migration and a plurality of resources with corresponding names. The system transmits a first plurality of interests for the resources indicated in the first manifest based on a corresponding name. The system receives a second manifest, wherein the migration phase indicated in the second manifest is a stop-and-copy phase. The system transmits a second plurality of interests for the resources indicated in the second manifest based on a corresponding name. The system starts the data model on the system based on content objects retrieved in response to the first and second plurality of interests.

RELATED APPLICATIONS

The subject matter of this application is related to the subject matterin the following applications:

-   -   U.S. patent application Ser. No. 13/847,814, entitled        “ORDERED-ELEMENT NAMING FOR NAME-BASED PACKET FORWARDING,” by        inventor Ignacio Solis, filed 20 Mar. 2013 (hereinafter “U.S.        patent application Ser. No. 13/847,814”);    -   U.S. patent application Ser. No. 12/338,175, entitled        “CONTROLLING THE SPREAD OF INTERESTS AND CONTENT IN A CONTENT        CENTRIC NETWORK,” by inventors Van L. Jacobson and Diana K.        Smetters, filed 18 Dec. 2008 (hereinafter “U.S. patent        application Ser. No. 12/338,175”); and    -   U.S. patent application Ser. No. 14/337,026, entitled “SYSTEM        FOR DISTRIBUTING NAMELESS OBJECTS USING SELF-CERTIFYING NAMES,”        by inventor Marc E. Mosko, filed 21 Jul. 2014 (hereinafter “U.S.        patent application Ser. No. 14/337,026”);        the disclosures of which are herein incorporated by reference in        their entirety.

BACKGROUND Field

This disclosure is generally related to distribution of digital content.More specifically, this disclosure is related to a method and system forprocess migration in a content centric network based on a namingontology and creation of checkpoint versions.

Related Art

The proliferation of the Internet and e-commerce continues to create avast amount of digital content. Content centric network (CCN)architectures have been designed to facilitate accessing and processingsuch digital content. A CCN includes entities, or nodes, such as networkclients, forwarders (e.g., routers), and content producers, whichcommunicate with each other by sending interest packets for variouscontent items and receiving content object packets in return. CCNinterests and content objects are identified by their unique names,which are typically hierarchically structured variable lengthidentifiers (HSVLI). An HSVLI can include contiguous name componentsordered from a most general level to a most specific level.

A CCN data packet (such as an interest or content object) is routedbased on its name. An interest can leave state in a pending interesttable (PIT) as it travels through the network. A responsive contentobject can be cached by any intermediate node in its content store (CS).This caching creates efficient access to frequently requested data,because a subsequent interest for the same content can be satisfied byan intermediate node, rather than by an end host such as a contentproducer.

Process migration involves moving the running state of a process fromone physical system to another, such as moving the state of a virtualmachine from one system to another. While a CCN brings many desiredfeatures to a network, some issues remain unsolved in providing a systemthat facilitates process migration over a content centric network.

SUMMARY

One embodiment provides a system that facilitates a migration of a datamodel from a source device to a target device in a CCN. The systemgenerates, by a target device, a first interest for a first manifestwhich represents a version of the data model, wherein a manifestindicates a phase of the migration and a plurality of machine resourceswith corresponding names. In response to receiving the first manifest,the system transmits a first plurality of interests for the resourcesindicated in the first manifest based on a name for a respectiveresource indicated in the first manifest. The system receives a secondmanifest, wherein the migration phase indicated in the second manifestis a stop-and-copy phase. The system transmits a second plurality ofinterests for the resources indicated in the second manifest based on aname for a respective resource indicated in the second manifest. Thesystem starts the data model on the system based on content objectsretrieved in response to the first and second plurality of interests,thereby facilitating the migration of the data model over a contentcentric network from a source device to the system. The system can be atarget device.

In some embodiments, generating the first interest, receiving the firstmanifest, and transmitting the first plurality of interests are inresponse to determining a pre-copy method for the migration of the datamodel. Receiving the second manifest is in response to retrievingcontent indicated in the first manifest and one or more checkpointmanifests.

In some embodiments, a respective checkpoint manifest indicates a uniqueversion identifier for the data model, the migration phase indicated inthe first manifest and a respective checkpoint manifest is a push phase,and the second manifest represents a hot version of the data model.

In some embodiments, the data model comprises an architecture for avirtual machine, and the resources are resources of the virtual machine.

In some embodiments, a name is a hierarchically structured variablelength identifier that includes contiguous name components ordered froma most general level to a most specific level. The name for a respectiveresource indicated in a manifest is a hash-based name which includes ahash value for data representing the respective resource. The hash-basedname for the respective resource allows the system to obtain therespective resource from any device that stores a content object with ahash value that matches the hash value included in the hash-based name,thereby facilitating de-duplication of data in the data model.

In some embodiments, receiving the second manifest is further inresponse to the source device determining that a predetermined marginalthreshold is reached and freezing the data model on the source device.

In some embodiments, the system receives a third manifest whichrepresents a final version of the data model, wherein the migrationphase indicated in the third manifest is a pull phase. The systemtransmits a third plurality of interests for the resources indicated inthe third manifest based on a name for a respective resource indicatedin the third manifest, wherein transmitting the third plurality ofinterests is based on a policy of the system.

In some embodiments, the system transmits a first interest which is aclose checkpoint message with a name that indicates a respectivemanifest. in response to receiving an acknowledgment of the firstinterest, the system transmits a second interest which is a confirmcheckpoint close message with a name that indicates the respectivemanifest. The system receives an acknowledgment of the second interest,wherein the source device releases the resources indicated in therespective manifest.

Another embodiment provides a system for facilitating a migration of adata model indicating resources. The system generates a first manifestwhich represents a version of the data model, wherein a manifestindicates a phase of the migration and a plurality of resources withcorresponding names. In response to receiving a first plurality ofinterests for the resources indicated in the first manifest based on aname for a respective resource indicated in the first manifest, thesystem transmits a first plurality of corresponding content objects. Inresponse to reaching a predetermined threshold, the system: freezes thedata model on the system; and generates a second manifest, wherein themigration phase indicated in the second manifest is a stop-and-copyphase. In response to receiving a second plurality of interests for theresources indicated in the second manifest based on a name for arespective resource indicated in the second manifest, the systemtransmits a second plurality of corresponding content objects, therebyfacilitating the migration of the data model over a content centricnetwork from the system to a target device. The system can be a sourcedevice.

In some embodiments, generating the first manifest, receiving the firstplurality of interests, and transmitting the first plurality of contentobjects are in response to determining a pre-copy method for themigration of the data model, wherein the migration phase indicated inthe first manifest is a push phase.

In some embodiments, the system generates one or more checkpointmanifests. A respective checkpoint manifest indicates a unique versionidentifier for the data model, the migration phase indicated in therespective checkpoint manifest is a push phase, and the second manifestrepresents a hot version of the data model.

In some embodiments, the system generates a third manifest whichrepresents a final version of the data model, wherein the migrationphase of the third manifest indicates a pull phase. In response toreceiving a third plurality of interests for the resources indicated inthe third manifest based on a name for a respective resource indicatedin the third manifest, the system transmits a third plurality ofcorresponding content objects.

In some embodiments, in response to receiving a first interest which isa close checkpoint message with a name that indicates a respectivemanifest, the system transmits an acknowledgment of the first interest.In response to receiving a second interest which is a confirm checkpointclose message with a name that indicates the respective manifest, thesystem: transmits an acknowledgment of the second interest; and releasesthe resources indicated in the respective manifest.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an exemplary network which facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention.

FIG. 2A illustrates an exemplary format for a checkpoint manifest, inaccordance with an embodiment of the present invention.

FIG. 2B illustrates an exemplary push phase checkpoint manifest, inaccordance with an embodiment of the present invention.

FIG. 2C illustrates an exemplary stop-and-copy phase checkpointmanifest, in accordance with an embodiment of the present invention.

FIG. 2D illustrates an exemplary pull phase checkpoint manifest, inaccordance with an embodiment of the present invention.

FIG. 3A illustrates an exemplary communication which facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention.

FIG. 3B illustrates an exemplary communication which facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention.

FIG. 4A presents a flow chart illustrating a method by a target devicefor facilitating process migration in a content centric network, inaccordance with an embodiment of the present invention.

FIG. 4B presents a flow chart illustrating a method by a target devicefor facilitating process migration in a content centric network, inaccordance with an embodiment of the present invention.

FIG. 5 presents a flow chart illustrating a method by a target devicefor closing a checkpoint during process migration in a content centricnetwork, in accordance with an embodiment of the present invention.

FIG. 6A presents a flow chart illustrating a method by a source devicefor facilitating process migration in a content centric network, inaccordance with an embodiment of the present invention.

FIG. 6B presents a flow chart illustrating a method by a source devicefor facilitating process migration in a content centric network, inaccordance with an embodiment of the present invention.

FIG. 7 illustrates an exemplary computer system that facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention.

In the figures, like reference numerals refer to the same figureelements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the embodiments, and is provided in the contextof a particular application and its requirements. Various modificationsto the disclosed embodiments will be readily apparent to those skilledin the art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present disclosure. Thus, the present invention is notlimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein.

Overview

Embodiments of the present invention provide a system which facilitatesprocess migration in a content centric network based on a namingontology and named checkpoint versions. A CCN data packet (such as aninterest or content object) is routed based on its name. An interest canleave state in a pending interest table (PIT) as it travels through thenetwork. A responsive content object can be cached by any intermediatenode in its content store (CS). This caching creates efficient access tofrequently requested data, because a subsequent interest for the samecontent can be satisfied by an intermediate node, rather than by an endhost such as a content producer.

Process migration can include moving the state of a virtual machine fromone physical system (i.e., a source device) to another physical system(i.e., a target device). One technique for progress migration is thepre-copy method, which involves three phases: the push phase; thestop-and-copy phase; and the pull phase, as described in Clark, et al.,“Live migration of virtual machines,” Proceedings of the 2^(nd)Conference on Symposium on Networked Systems Designs & Implementation,Vol. 2, pages 273-286, USENIX Association, 2005. In the push phase,slowly changing state is moved over the network, possibly in severalrounds. In the stop-and-copy phase, the source virtual machine freezes,and the hot state is moved over the network. In the pull phase, anyremaining data not copied over is moved over the network (e.g., thetarget can “lazily” pull the data on-demand or at its desired pace).

Another technique for process migration is the post-copy method, wherebythe source first freezes the virtual machine and transfers the CPU state(similar to the stop-and-copy phase of the pre-copy method), and thentransfers the memory (similar to both the push and pull phases of thepre-copy method), as described in Hines, et al., “Post-copy based livevirtual machine migration using adaptive pre-paging and dynamicself-ballooning,” Proceedings of the 2009 ACM SIGPLAN/SIGOPSInternational Conference on Virtual Execution Environments, pages 51-60,ACM, 2009. Other process migration techniques are possible, includingthe Remus hot migration, which uses consistent and frequent checkpointsfor hot-spare virtual machine migration, as described in Cully, et al.,“Remus: High availability via asynchronous virtual machine replication,”Proceedings of the 5^(th) USENIX Symposium on Networked Systems Designand Implementation, pages 161-174, San Francisco, 2008.

Embodiments of the present invention provide a system based on thepre-copy process migration technique which facilitates process migrationover a CCN by mapping machine elements to CCN names. The system useshash-based formatted names and manifests via CCN interests and contentobjects to identify, represent, and move the machine resources.Hash-based names (i.e., nameless content objects) are described in U.S.patent application Ser. No. 14/337,026. The system includes strongcheckpointing and data de-duplication. The system creates namedcheckpoint manifests in the three phases of the pre-copy technique,where a named checkpoint corresponds to a specific version of a machinemodel. Exemplary checkpoint manifests are described below in relation toFIGS. 2A-2D, and an exemplary communication that facilitates processmigration in a CCN based on formatted names is described below inrelation to FIGS. 3A and 3B.

Thus, the present system provides improvements to the distribution ofdigital content, where the improvements are fundamentally technological.Embodiments of the present invention provide a technological solution(e.g., facilitating process migration over a CCN based on a pre-copymethod using interest/content object exchanges and manifests) to thetechnological problem of efficiently migrating a process, such as a datamodel or a virtual machine, over a CCN.

In CCN, each piece of content is individually named, and each piece ofdata is bound to a unique name that distinguishes the data from anyother piece of data, such as other versions of the same data or datafrom other sources. This unique name allows a network device to requestthe data by disseminating a request or an interest that indicates theunique name, and can obtain the data independent from the data's storagelocation, network location, application, and means of transportation.The following terms are used to describe the CCN architecture:

Content Object (or “content object”): A single piece of named data,which is bound to a unique name. Content Objects are “persistent,” whichmeans that a Content Object can move around within a computing device,or across different computing devices, but does not change. If anycomponent of the Content Object changes, the entity that made the changecreates a new Content Object that includes the updated content, andbinds the new Content Object to a new unique name.

Unique Names: A name in a CCN is typically location independent anduniquely identifies a Content Object. A data-forwarding device can usethe name or name prefix to forward a packet toward a network node thatgenerates or stores the Content Object, regardless of a network addressor physical location for the Content Object. In some embodiments, thename may be a hierarchically structured variable-length identifier(HSVLI). The HSVLI can be divided into several hierarchical components,which can be structured in various ways. For example, the individualname components parc, home, ccn, and test.txt can be structured in aleft-oriented prefix-major fashion to form the name“/parc/home/ccn/test.txt.” Thus, the name “/parc/home/ccn” can be a“parent” or “prefix” of “/parc/home/ccn/test.txt.” Additional componentscan be used to distinguish between different versions of the contentitem, such as a collaborative document. The HSVLI can also includecontiguous name components ordered from a most general level to a mostspecific level.

In some embodiments, the name can include an identifier, such as a hashvalue that is derived from the Content Object's data (e.g., a checksumvalue) and/or from elements of the Content Object's name. A descriptionof a hash-based name is described in U.S. patent application Ser. No.13/847,814, which is herein incorporated by reference. A name can alsobe a flat label. Hereinafter, “name” is used to refer to any name for apiece of data in a name-data network, such as a hierarchical name orname prefix, a flat name, a fixed-length name, an arbitrary-length name,or a label (e.g., a Multiprotocol Label Switching (MPLS) label).

Interest (or “interest”): A packet that indicates a request for a pieceof data, and includes a name (or a name prefix) for the piece of data. Adata consumer can disseminate a request or Interest across aninformation-centric network, which CCN/NDN routers can propagate towarda storage device (e.g., a cache server) or a data producer that canprovide the requested data to satisfy the request or Interest.

The methods disclosed herein are not limited to CCN networks and areapplicable to other architectures as well. A description of a CCNarchitecture is described in U.S. patent application Ser. No.12/338,175, which is herein incorporated by reference.

A Classic Machine Model and Exemplary Formatted Names

A classic machine model includes a central processing unit (CPU) with aregister file, random access memory (RAM), permanent storage (e.g., harddisks), and accessories (e.g., network interface cards or a graphicssystem), as well as a configuration file describing the systemarchitecture. The machine model (or any data model) and its constituentresources can be mapped to names and corresponding content objects. Theconfiguration file can specify the hardware parameters, including thenumber of CPUs (including identifiers, e.g., where “cpu_n,” is the nthCPU), the amount of RAM and the page size (e.g., 1 GB with 4 KB pages),the number of hard disks (including identifiers, e.g., “hdA” and “hdB”),and network interfaces (e.g., “en0”). A hard disk may be represented inthe Virtual Hard Disk (“vhd”) format and includes its own configurationfile in addition to data blocks (e.g., 512 bytes or 4 KB, per theconfiguration file). A standard disk model, such as vhd, uses threecontrol structures in addition to the data blocks: a dynamic diskheader; a block allocation table (BAT); and a disk footer. The CCNnaming ontology maps each machine element or resource to a CCN name.Below are exemplary names for resources of a virtual machine with aroutable prefix or identifier of “/vm-name,” n CPUs, x pages of RAM, twohard disks (hdA and hdB, where at least hdA is of the vhd format) eachwith y blocks, and a network interface of en0:

/vm-name/config Format (1)

/vm-name/cpu∧{0 . . . cpu_n\}regfile Format (2)

/vm-name/cpu∧{0 . . . cpu_n \}/tlb Format (3)

/vm-name/ram/page/{0 . . . ram_x} Format (4)

/vm-name/disk/hda/config Format (5)

/vm-name/disk/hda/vhd/header Format (6)

/vm-name/disk/hda/vhd/bat Format (7)

/vm-name/disk/hda/vhd/footer Format (8)

/vm-name/disk/hda/block/{0 . . . hda_y} Format (9)

/vm-name/disk/hdb/config Format (10)

/vm-name/disk/hdb/block/{0 . . . hdb_y} Format (11)

/vm-name/net/en0 Format (12)

Process Migration Using Pre-Copy Technique and Hash-Based Names

The following assumptions may be made: A supervisory process determinesthe need to begin a migration process, i.e., to move a process from asource or source device to a target or target device. The supervisoryprocess can instantiate a process duplicator agent on each of the sourceand the target, such as in the virtual machine hypervisor. Furthermore,the agents have a reliable transfer method, and the source and thetarget can agree on a window size or acknowledgment mechanism so thatthe source can release resources which have been correctly transferredto the target. Finally, the source and the target have a reliable closemechanism, such as the four-way handshake described below in relation toFIG. 5.

The system can facilitate process migration over a CCN based on thethree phases of the pre-copy technique and the specific naming ontology.In the push phase, the source creates versioned checkpoint manifests,which are pulled by the target. The target then retrieves the datarepresented in the checkpoint manifest via the naming ontology. Thesource and the target iterate through the push phase until the sourcedetermines a marginal benefit. In the stop-and-copy phase, the sourcefreezes the data model (e.g., the virtual machine), creates a nextcheckpoint manifest of critical resources, and transfers the nextcheckpoint manifest to the target. Finally, in the pull phase, thesource creates a final checkpoint manifest, which the target can lazilypull as needed. This three-phase process, along with hash-basedformatted names following the naming ontology, is described below in theexemplary communications of FIGS. 3A and 3B.

The naming ontology follows the formatted names described above for theexemplary machine model. For example, in the push phase, a checkpointmanifest can have a name such as “/vm-name/checkpoint/ver=j/manifest”while a resource represented in the checkpoint manifest can beretrieving using a hash-based name. For example, an interest for theresource can have a name of“/vm-name/checkpoint/ver=j/resource=ram/feature=page_1/hash=hash_p1” or“/vm-name/chkpt/ver=0/ram/page_1/hash_p1.” Exemplary checkpointmanifests are described below in relation to FIGS. 2A-2D.

Exemplary Network

FIG. 1 illustrates an exemplary network 100 which facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention. Network 100 can include a consumer or contentrequesting device 116, producers or content producing devices 118 and120, and a router or other forwarding device at nodes 102, 104, 106,108, 110, 112, and 114. A node can be a computer system, an end-pointrepresenting users, and/or a device that can generate interests ororiginate content. A node can also be an edge router (e.g., CCN nodes102, 104, 110, and 114) or a core router (e.g., intermediate CCN routers106, 108, and 112). Network 100 can be a content centric network. Device118 can be a source device, and device 158 can be a target device.Source device 118 can run a virtual machine 120, which can include thefollowing components or resources: a configuration file 122; a CPU 124;a RAM 126; a hard disk A 128; a hard disk B 130; and a network interface132. Hard disk A 128 can be of a vhd format, and can include aconfiguration file 140, a vhd 142, and a block 144. While only one block144 is depicted in FIG. 1, hard disk A 128 can include multiple blocks.Vhd 144 can include a header 150, a BAT 152, and a footer 154. Targetdevice 158 can run a virtual machine 160 with similar resources (notshown) as virtual machine 120 running on source device 118. Sourcedevice 118 and target device 158 can participate in a migration process,which involves moving the state of virtual machine 120 from sourcedevice 118 to (virtual machine 160) on target device 158.

During operation, target device 158 can communicate with source device118 by sending an interest 170 which travels through network 100 vianodes 114, 112, and 110 before reaching source device 118. Source device118 can satisfy interest 170 and return a responsive content object 172.For example, interest 170 can be an interest for a checkpoint manifestwhich represents a version of the data model for virtual machine 120,and content object 172 can be the responsive checkpoint manifest. A namefor interest 170 (and responsive content object 172 can be“/vm-name/checkpoint/ver=0/manifest.” The manifest can indicate thephase of the process migration (e.g., push, stop-and-copy, or pull) aswell as the resources with corresponding names, including hash-basednames.

Upon receiving the manifest, target device 158 can generate interestsfor the indicated resources using the corresponding hash-based names.Target device 158 can retrieve the corresponding content objects fromsource device 118 or from any intermediate node that may have a cachedcopy of the corresponding content objects. For example, node 112 maystore a cached copy of a content object with a name of“/vm-name/checkpoint/ver=0/ram/page_1/hash_p1,” that is, a contentobject whose hash is equal to “hash_p1” as included in the name of therespective interest. Thus, intermediate node 112 can return a responsivecontent object 172 to target device 158. The caching features of a CCNalso result in de-duplication, which is described in detail below. Adetailed description of the push, stop-and-copy, and pull phases in aprocess migration over a CCN is described below in relation to FIGS. 3Aand 3B.

Exemplary Versioned Checkpoint Manifests

FIG. 2A illustrates an exemplary format for a checkpoint manifest 200,in accordance with an embodiment of the present invention Checkpointmanifest 200 can indicate a phase 202, a configuration 204, and a listof resources 206, where a resource can include one or more tuplescomprised of a feature 208 and a hash 210.

FIG. 2B illustrates an exemplary push phase checkpoint manifest 210, inaccordance with an embodiment of the present invention. Manifest 210 canindicate a phase 212 with a value of “push,” a configuration file 214with a value of “<data, hash, or link>,” a CPU 216 resource with a valueof “cpu_1,” a RAM 218 resource with a value of “ram,” a hard disk 220resource with a value of “hdA,” and a hard disk 222 resource with avalue of “hdB.” CPU 212 can include the following {feature, hash}tuples: {regfile, hash_regfile}; and {tlb, hash_tlb}. RAM 218 canindicate the following {feature, hash} tuples: {page_0, hash_p0};{page_1, hash_p1}; and {page_2, hash_p2}. Hard disk 220 can indicate thefollowing {feature, hash} tuples: {config_A, hash_configA}; {vhd/header,hash_vhdr}; {vhd/bat, hash_vbat}; {vhd/footer, hash_vftr}; {block_0,hash_ab0}; {block_1, hash_ab1}; and {block_2, hash_ab2}. Hard disk 222can indicate the following {feature, hash} tuples: {config_B,hash_configB}; {block_0, hash_bb0}; {block_1, hash_bb1}; and {block_2,hash_bb2}.

FIG. 2C illustrates an exemplary stop-and-copy phase checkpoint manifest230, in accordance with an embodiment of the present invention. Manifest230 can indicate a phase 232 with a value of “stop-and-copy,” aconfiguration file 234 with a value of “<data, hash, or link>,” a CPU236 resource with a value of “cpu_1,” and a RAM 238 resource with avalue of “ram.” CPU 236 can indicate the following {feature, hash}tuples: {regfile, hash_regfile}; and {tlb, hash_tlb}. CPU 236 can alsoindicate other essential CPU state in stop-and-copy checkpoint manifest230. RAM 238 can indicate the following {feature, hash} tuples:{page_20, hash_p20}; {page_21, hash_p21}; {page_22, hash_p22}; {page_54,hash_p54}; {page_55, hash_p55}; and {page_56, hash_p56}. RAM 238 canalso indicate other high turnover pages in stop-and-copy manifest 230.

FIG. 2D illustrates an exemplary pull phase checkpoint manifest 250, inaccordance with an embodiment of the present invention. Manifest 250 canindicate a phase 252 with a value of “pull,” a RAM 254 resource with avalue of “ram,” a hard disk 256 resource with a value of “hdA,” and ahard disk 258 resource with a value of “hdB.” RAM 254 can indicate thefollowing {feature, hash} tuples: {page_4, hash_p4}; and {page_8,hash_p8}. Hard disk 256 can indicate the following {feature, hash}tuples: {block_88, hash_ab88}; {block_98, hash_ab98}; and {block_99,hash_ab99}. Hard disk 258 can indicate the following {feature, hash}tuples: {block_49, hash_bb49}; and {block_54, hash_bb54}.

Each of checkpoint manifest 200, push phase checkpoint manifest 210,stop-and-copy phase manifest 230, and pull phase checkpoint manifest 250can also include a name and a version field (not shown). Each resourceindicated in a manifest can be retrieved by generating an interest witha name in the format of, e.g., Formats (1)-(12), where a last namecomponent is the corresponding hash value for the resource or thespecific feature of the resource. A responsive content object with thesame name as the interest is thus retrieved by (and transferred to) thetarget device. For example, an interest with a name of“/vm-name/checkpoint/ver=15/ram/page_1/hash_p1” will return a contentobject with the same name. Chunk numbers may also be used when a contentobject representing a resource is larger in size than a single contentobject. In this case, the interest name can be, e.g.,“/vm-name/checkpoint/ver=15/chunk=k/ram/page_1/hash_p1.”

Exemplary Communication Facilitating Process Migration over a CCN

FIG. 3A illustrates an exemplary communication 300 which facilitatesprocess migration in a content centric network, in accordance with anembodiment of the present invention. Communication 300 includes a sourceor source device 302 and a target or target device 304, which cancommunicate over a network such as a CCN. A supervisory process candetermine the need to migrate a data model (such as a process like avirtual machine model) from source 302 to target 304. Target 304 andsource 302 can participate in a push phase 306, a stop-and-copy phase308, and a pull phase 310 (in FIG. 3B).

Target 304 can generate an interest 312 with a name of“/vm-name/chkpt/ver=0/manifest,” which represents a version of the datamodel. In some embodiments, version 0 indicates an initial image of thedata model. Source 302 can generate and return a responsive contentobject 314 with the same name as the interest name. Content object 314can be, e.g., push phase checkpoint manifest 210 of FIG. 2B.

Target 304 can retrieve the checkpoint manifest (function 316), whichinvolves transmitting a plurality of interests for the resourcesindicated in the checkpoint manifest. Each interest has a name whichindicates the resource and can include a specific feature andcorresponding hash value. For example, target 304 can generate aninterest 318.1 with a name of“/vm-name/chkpt/ver=0/disk/hdA/block_0/hash_ab0” and receive aresponsive content object 320.1 with the same name and which includes asits payload the data corresponding to the specific resource.

Upon retrieving all the content objects indicated in manifest 314,target 304 can close the checkpoint (function 322), which involves afour-way handshake. Target 304 can send an interest 324 with a name of“/vm-name/checkpt/ver=0/close” and receive from source 302 a responsiveACK content object 326 with the same name. The ACK can be indicated in apayload of content object 326 or in another field. Target 304 can thensend an interest 328 with a name of “/vm-name/chkpt/ver=0/confirm_close”and receive from source 302 a responsive ACK content object 330 with thesame name. Interest 324 can be a close checkpoint message, and interest328 can be a confirm checkpoint close message. Source 302 can releasethe resources (function 332) associated with the respective manifest(i.e., version 0 of the checkpoint manifest). Target 304 and source 302can iterate through push phase 306 until source 302 determines that apredetermined marginal threshold is reached (function 333) (i.e.,transferring a push checkpoint manifest only results in a marginalbenefit).

Upon making this determination, source 302 can freeze the data model onsource 302 (function 334) and create a stop-and-copy (“stp”) checkpointmanifest (function 336). Source 302 can send a content object 338 whichis an stp checkpoint manifest with a name of, e.g.,“/vm-name/chkpt/ver=15/manifest.” In some embodiments, source 302 sendscontent object 338 in response to an interest (from target 304) with thesame name as the content object name. Content object 314 can be, e.g.,stop-and-copy phase checkpoint manifest 230 of FIG. 2C.

Target 304 can retrieve the stp checkpoint manifest (function 340),which involves transmitting a plurality of interests for the resourcesindicated in the stp checkpoint manifest. Each interest has a name whichindicates the resource and can include a specific feature andcorresponding hash value. For example, target 304 can generate aninterest 342.1 with a name of“/vm-name/chkpt/ver=15/ram/page_20/hash_p20” and receive a responsivecontent object 344.1 with the same name and which includes as itspayload the data corresponding to the specific resource.

Upon retrieving all the content objects indicated in manifest 338,target 304 can start the data model on target 304 (function 346) andclose the checkpoint (function 348), which involves the four-wayhandshake described above and applied to interest 350, content object352, interest 354, and content object 356. Source 302 can release theresources (function 338) associated with the respective manifest (i.e.,version 15 of the checkpoint manifest, or the stp checkpoint manifest).

FIG. 3B illustrates an exemplary communication 360 which facilitatesprocess migration in a content centric network, in accordance with anembodiment of the present invention. Subsequent to the communicationsdescribed in FIG. 3A, source 302 can create a final checkpoint manifest362. Source 302 can send a content object 364 which is a finalcheckpoint manifest with a name of, e.g.,“/vm-name/chkpt/ver=F/manifest.” In some embodiments, source 302 sendscontent object 364 in response to an interest (from target 304) with thesame name as the content object name. The version “F” refers to a finalversion, and can also be a version number or identifier greater than theversion number or identifier for the previously transferred manifest.Content object 364 can be, e.g., pull phase checkpoint manifest 250 ofFIG. 2D.

Target 304 can retrieve the final checkpoint manifest (function 366),which involves transmitting a plurality of interests for the resourcesindicated in the final manifest. Each interest has a name whichindicates the resource and can include a specific feature andcorresponding hash value. For example, target 304 can generate aninterest 368.1 with a name of“/vm-name/chkpt/ver=F/disk/hdB/block_54/hash_bb54” and receive aresponsive content object 370.1 with the same name and which includes asits payload the data corresponding to the specific resource. Because themost crucial information has already been transferred to target 304 (instop-and-copy phase 308), and because the data model is already runningon target 304, target 304 can perform function 366 on demand (i.e., a“lazy” pull at a pace of its choosing).

Upon retrieving all the content objects indicated in manifest 364,target 304 can close the checkpoint (function 372), which involves thefour-way handshake described above and applied to interest 374, contentobject 376, interest 378, and content object 380. Source 302 can releasethe resources (function 382) associated with the respective manifest(i.e., version F of the checkpoint manifest, or the final checkpointmanifest).

Thus, communications 300 and 360 illustrate how the system facilitatesprocess migration over a CCN, based on the three phases of the pre-copytechnique, and further based on standard CCN interest and content objectpackets with hash-based formatted names. Other process migrationtechniques are possible, including the post-copy technique and the Remushot migration technique.

How Nameless Content Objects Facilitate De-Duplication

De-duplication is a technique where only one copy of data exists and theone copy is shared between multiple instances. In CCN, resources can bede-duplicated and shared both within and between virtual machineinstances. For example, two disk blocks that have the same hash valuerefer to the same content object. In this case, only the block index inthe manifest is different.

A virtual machine hypervisor may also share blocks between virtualmachines. When generating the names used to retrieve content indicatedin a checkpoint manifest, the source migration agent running in thesource hypervisor can use a name such as “/nyc/host/hash=0x6333” so thatany instance or any component can share the same data. If the size of amemory page and the size of a disk block are the same, the data orcontent object with this name can be both a disk block and a RAM page ofthe same data (e.g., a shared library code section). The checkpointmanifest can point to different names prefixes for each hash value, andcan indicate the virtual resource corresponding to the hash value. Thus,the same physical bytes may be used for many purposes.

As an example, a migration agent may know that some disk blocks arecommon. The hard disk hdA can mount a read-only root file system thatonly contains common operating system and application binary resources.These may be associated with a name prefix such a “/nyc/objectstore” andmay be shared over many different physical hosts. The checkpointmanifest allows these resources to come from the specific name prefixand also allow other resources to come from a host-specific or virtualmachine-specific location. Thus, the system allows for de-duplication ofdata based on the CCN naming ontology and further based on retrieval ofcontent from both cached copies and varying prefix-based locations.

Routing and Control Channel

The system can manage routing in several ways. We assume that allsystems have a unique name (e.g., “/nyc/host7/vm-name”) possibly inaddition to a generic name (e.g., “/vm-name”). Three routing models arepossible. The first routing model is the external model, where anexternal agency or agencies manage the routing namespace. One example isa typical CCN interest. In the external model, the source and targetmigration agents can have different names. The source may have the nameprefix “/nyc/host7/vm-name” and the target may have the name prefix“/sfo/host2/vm-name.” A migration orchestrator (e.g., a supervisoryprocess) can understand these names and appropriately instruct themigration agents of the correct names.

The second routing model is the software-defined model, where a centralbut programmable agency manages the routing namespace, such as asoftware-defined network environment. In the software-defined model,generic names such as “/vm-name” may be used. Prior to and during thestop-and-copy phase, the name points to the source agent. After thestop-and-copy phase, when the target is ready to start the data model orvirtual machine, the target notifies the network controller to point“vm-name” to the target. This leaves the source with only itslocation-dependent name, “/nyc/host7/vm-name,” which is used in the pullphase to transfer any remaining data.

The third routing model is the distributed model, where the endpointsmanage the routing namespace, e.g., by running a secure routing process.In the distributed model, the source agent advertises “/vm-name” untilthe completion of the stop-and-copy phase. After this point, the sourceagent stops advertising the name, and the destination agent beginsadvertising the name. The destination may then finish transferring datain the pull phase using the location-dependent name of the source agent,e.g., “/nyc/host7/vm-name.”

CCNx routing can be set up such that “/vm-name” points to the correctlocation of the source system. The target agent can poll the sourceagent until the source agent is running, and the target agent can thenrequest the first checkpoint (e.g., by issuing interest 312 in FIG. 3A).After a specific checkpoint is transferred, the target agent can pullthe next checkpoint version (e.g., by iterating through push phase 306of FIG. 3A).

Recall that each checkpoint manifest indicates the phase (or purpose) ofthe manifest (i.e., push, stop-and-copy, or pull). The target thus knowsto keep its data model (or virtual machine) frozen while receiving apush phase manifest and retrieving the indicated content. The targetalso knows to start the data model after receiving the stop-and-copyphase manifest and retrieving the indicated content. Upon starting thedata model, the target also knows to retrieve the final manifest for thenext checkpoint version, which is the remaining uncopied data which thetarget agent can subsequently pull or retrieve at its leisure.

Target Device Facilitates Process Migration Over a CCN

FIG. 4A presents a flow chart 400 illustrating a method by a targetdevice for facilitating process migration in a content centric network,in accordance with an embodiment of the present invention. Duringoperation, a target device determines whether a pre-copy method is usedfor a migration of a data model (decision 402). If the pre-copy methodis not being used, and another method such as a post-copy method isbeing used, the operation continues at operation 412. If the pre-copymethod is being used, the target device generates a first interest for afirst manifest which represents a checkpoint version of the data model,wherein a manifest indicates a phase of the migration and a plurality ofresources with corresponding names, wherein the migration phaseindicated in the first manifest is a push phase (operation 404). Inresponse to receiving the first manifest, the target device transmits afirst plurality of interests for the resources indicated in the firstmanifest based on a name for a respective resource indicated in thefirst manifest (operation 406). The target device retrieves contentobjects in response to the first plurality of interests (operation 408).The target device closes the checkpoint corresponding to the firstmanifest (operation 410, and as described below in relation to FIG. 5).

The target device receives a second manifest which represents a hotversion of the data model, wherein the migration phase indicated in thesecond manifest is a stop-and-copy phase (operation 412). Receiving thesecond manifest is in response to the source device reaching apredetermined threshold (i.e., determining that marginal benefits resultfrom transferring a checkpoint manifest, as in function 333 of FIG. 3A).Receiving the second manifest is further in response to the sourcedevice freezing the data model on the source device (as in function 334of FIG. 3A). In response to receiving the second manifest, the targetdevice transmits a second plurality of interests for the resourcesindicated in the second manifest based on a name for a respectiveresource indicated in the second manifest (operation 414). The targetdevice retrieves content objects in response to the second plurality ofinterests (operation 416), and the operation continues at Label A ofFIG. 4A.

FIG. 4B presents a flow chart illustrating a method by a target devicefor facilitating process migration in a content centric network, inaccordance with an embodiment of the present invention. Duringoperation, the target device closes the checkpoint corresponding to thesecond manifest (operation 422, and as described below in relation toFIG. 5). The target device starts the data model on the target devicebased on the retrieved content objects (operation 424).

The target device receives a third manifest which represents a finalversion of the data model, wherein the migration phase indicated in thethird manifest is a pull phase (operation 426). In some embodiments,such as a process migration based on a post-copy method, there may bemore than one single “final” pull checkpoint manifest. The target devicetransmits a third plurality of interests for the resources indicated inthe third manifest based on a name for a respective resource indicatedin the third manifest, wherein transmitting the third plurality ofinterests is based on a policy of the target device (operation 428). Thetarget device retrieves content in response to the third plurality ofinterests (operation 430). The target device closes the checkpointcorresponding to the third manifest (operation 432, and as describedbelow in relation to FIG. 5).

Closing a Checkpoint

FIG. 5 presents a flow chart 500 illustrating a method by a targetdevice for closing a checkpoint during process migration in a contentcentric network, in accordance with an embodiment of the presentinvention. Closing a checkpoint may be initiated by a target device, andcan occur after the target device finishes retrieving all dataassociated with a respective checkpoint manifest. During operation, atarget device transmits a first interest which is a close checkpointmessage with a name that indicates a respective manifest (operation502). In response to receiving an acknowledgment of the first interest,the target device transmits a second interest which is a confirmcheckpoint close message with a name that indicates the respectivemanifest (operation 504). The target device receives an acknowledgementof the second interest, wherein the source device releases the resourcesindicated in the respective manifest (operation 506).

Source Device Facilitates Process Migration Over a CCN

FIG. 6A presents a flow chart 600 illustrating a method by a sourcedevice for facilitating process migration in a content centric network,in accordance with an embodiment of the present invention. Duringoperation, a source device determines whether a pre-copy method is usedfor a migration of a data model (decision 602). If the pre-copy methodis not being used, and another method such as a post-copy method isbeing used, the operation continues at operation 612. If the pre-copymethod is being used, the source device generates a first manifest whichrepresents a checkpoint version of the data model, wherein a manifestindicates a phase of the migration and a plurality of resources withcorresponding names, wherein the migration phase indicated in the firstmanifest is a push phase (operation 604). The first manifest can be acheckpoint manifest which indicates a unique version identifier for thedata model. In response to receiving a first plurality of interests forthe resources indicated in the first manifest based on a name for arespective resource indicated in the first manifest, the source devicetransmits a first plurality of corresponding content objects (operation606). The source device closes the checkpoint corresponding to the firstmanifest and releases the resources indicated in the first manifest(operation 608, and as described below in relation to FIG. 5).

The source device determines whether a pre-determined threshold has beenreached (decision 610) (i.e., marginal benefits result from transferringa checkpoint manifest, as in function 333 of FIG. 3A). If the thresholdis not reached, the operation returns to operation 604, i.e., generatingand transferring another checkpoint manifest to the target device. Ifthe threshold is reached, the source device freezes the data model onthe source device (as in function 334 of FIG. 3A), and the operationcontinues at Label B of FIG. 6B.

FIG. 6B presents a flow chart 620 illustrating a method by a sourcedevice for facilitating process migration in a content centric network,in accordance with an embodiment of the present invention. Duringoperation, the source device generates a second manifest whichrepresents a hot version of the data model, wherein the migration phaseindicated in the second manifest is a stop-and-copy phase (operation622). In response to receiving a second plurality of interests for theresources indicated in the second manifest based on a name for arespective resource indicated in the second manifest, the source devicetransmits a second plurality of corresponding content objects (operation624). When the target receives the second plurality of correspondingcontent objects, the target device starts the data model on the targetdevice (as in operation 424 of FIG. 4B). The source device closes thecheckpoint corresponding to the second manifest and releases theresources indicated in the second manifest (operation 626, and asdescribed below in relation to FIG. 5).

The source device generates a third manifest which represents a finalversion of the data model, wherein the migration phase indicated in thethird manifest is a pull phase (operation 628). In some embodiments,including process migration based on a post-copy method, there may bemore than one single “final” pull checkpoint manifest. In response toreceiving a third plurality of interests for the resources indicated inthe third manifest based on a name for a respective resource indicatedin the third manifest, the source device transmits a third plurality ofcorresponding content objects (operation 630). The source device closesthe checkpoint corresponding to the third manifest and releases theresources indicated in the third manifest (operation 632, and asdescribed below in relation to FIG. 5).

Exemplary Computer System

FIG. 7 illustrates an exemplary computer system that facilitates processmigration in a content centric network, in accordance with an embodimentof the present invention. Computer system 702 includes a processor 704,a memory 706, and a storage device 708. Computer system 702 can be asource device or a target device for a migration of a data model. Memory706 can include a volatile memory (e.g., RAM) that serves as a managedmemory, and can be used to store one or more memory pools. Furthermore,computer system 702 can be coupled to a display device 710, a keyboard712, and a pointing device 714. Storage device 708 can store anoperating system 716, a content-processing system 718, and data 730.

Content-processing system 718 can include instructions, which whenexecuted by computer system 702, can cause computer system 702 toperform methods and/or processes described in this disclosure.Specifically, content-processing system 718 may include instructions forsending and/or receiving data packets to/from other network nodes acrossa computer network, such as a content centric network (communicationmodule 720). A data packet can include an interest packet or a contentobject packet with a name which is an HSVLI that includes contiguousname components ordered from a most general level to a most specificlevel. The name can be a hash-based name, where the last name componentis the hash value of the respective content object. A data packet canalso include a manifest or an acknowledgment.

Further, content-processing system 718 can include instructions forgenerating a first interest for a first manifest which represents aversion of the data model (interest-generating module 724).Content-processing system 718 can include instructions for, in responseto receiving the first manifest, transmitting a first plurality ofinterests for the resources indicated in the first manifest based on aname for a respective resource indicated in the first manifest(communication module 720 and interest-generating module 724).Content-processing system 718 can include instructions for starting thedata model on the system based on content objects retrieved in responseto the first plurality of interests and other interests for otherresources indicated in other manifests (data model-managing module 728).

Content-processing system 718 can include instructions for transmittinga first interest which is a close checkpoint message with a name thatindicates a respective manifest (communication module 720 andinterest-generating module 724). Content-processing system 718 caninclude instructions for, in response to receiving an acknowledgment ofthe first interest, transmitting a second interest which is a confirmcheckpoint close message with a name that indicates the respectivemanifest (communication module 720 and interest-generating module 724).Content-processing system 718 can include instructions for receiving anacknowledgment of the second interest (communication module 720).

Content-processing system 718 can include instructions for generating afirst manifest which represents a version of the data model(manifest-generating module 722). Content-processing system 718 caninclude instructions for, in response to receiving a first plurality ofinterests for the resources indicated in the first manifest based on aname for a respective resource indicated in the first manifest,transmitting a first plurality of corresponding content objects(communication module 720 and content-generating module 726).Content-processing system 718 can include instructions for, in responseto reaching a predetermined threshold (threshold-determining module730): freezing the data model on the system (data model-managing module728); and generating a second manifest (manifest-generating module 722).

Data 732 can include any data that is required as input or that isgenerated as output by the methods and/or processes described in thisdisclosure. Specifically, data 732 can store at least: an interest; acontent object; a name; a name that is an HSVLI that includes contiguousname components ordered from a most general level to a most specificlevel; a routable prefix or a name prefix that indicates one or morecontiguous name components beginning from the most general level; amanifest; a data model; a version number or identifier of a data model;a phase of a migration; resources and corresponding names; a hash-basedname; a hash value of data representing a resource; an indicator of apre-copy technique, a post-copy technique, or any other migrationtechnique; an indicator of a push, stop-and-copy, or pull phase; aninstruction to freeze or start a data model; a virtual machinearchitecture; a manifest which represents a collection of data includingresources, features, and hash values; a configuration file or link; apredetermined marginal threshold; a checkpoint version of a data model;a message; an acknowledgment of a message; a close checkpoint message; aconfirm checkpoint close message; and an indicator of a manifest.

The data structures and code described in this detailed description aretypically stored on a computer-readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. The computer-readable storage medium includes, but is notlimited to, volatile memory, non-volatile memory, magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs),DVDs (digital versatile discs or digital video discs), or other mediacapable of storing computer-readable media now known or later developed.

The methods and processes described in the detailed description sectioncan be embodied as code and/or data, which can be stored in acomputer-readable storage medium as described above. When a computersystem reads and executes the code and/or data stored on thecomputer-readable storage medium, the computer system performs themethods and processes embodied as data structures and code and storedwithin the computer-readable storage medium.

Furthermore, the methods and processes described above can be includedin hardware modules. For example, the hardware modules can include, butare not limited to, application-specific integrated circuit (ASIC)chips, field-programmable gate arrays (FPGAs), and otherprogrammable-logic devices now known or later developed. When thehardware modules are activated, the hardware modules perform the methodsand processes included within the hardware modules.

The foregoing descriptions of embodiments of the present invention havebeen presented for purposes of illustration and description only. Theyare not intended to be exhaustive or to limit the present invention tothe forms disclosed. Accordingly, many modifications and variations willbe apparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention. The scope ofthe present invention is defined by the appended claims.

What is claimed is:
 1. A computer system for facilitating a migration ofa data model indicating resources, the system comprising: a processor;and a storage device storing instructions that when executed by theprocessor cause the processor to perform a method, the methodcomprising: generating a first interest for a first manifest whichrepresents a version of the data model, wherein a manifest indicates aphase of the migration and a plurality of resources with correspondingnames; in response to receiving the first manifest, transmitting a firstplurality of interests for the resources indicated in the first manifestbased on a name for a respective resource indicated in the firstmanifest; receiving a second manifest, wherein the migration phaseindicated in the second manifest is a stop-and-copy phase; transmittinga second plurality of interests for the resources indicated in thesecond manifest based on a name for a respective resource indicated inthe second manifest; and starting the data model on the system based oncontent objects retrieved in response to the first and second pluralityof interests, thereby facilitating the migration of the data model overa content centric network from a source device to the system.
 2. Thecomputer system of claim 1, wherein generating the first interest,receiving the first manifest, and transmitting the first plurality ofinterests are in response to determining a pre-copy method for themigration of the data model, and wherein receiving the second manifestis in response to retrieving content indicated in the first manifest andone or more checkpoint manifests.
 3. The computer system of claim 2,wherein a respective checkpoint manifest indicates a unique versionidentifier for the data model, wherein the migration phase indicated inthe first manifest and a respective checkpoint manifest is a push phase,and wherein the second manifest represents a hot version of the datamodel.
 4. The computer system of claim 1, wherein the data modelcomprises an architecture for a virtual machine, and wherein theresources are resources of the virtual machine.
 5. The computer systemof claim 1, wherein a name is a hierarchically structured variablelength identifier that includes contiguous name components ordered froma most general level to a most specific level, wherein the name for arespective resource indicated in a manifest is a hash-based name whichincludes a hash value for data representing the respective resource, andwherein the hash-based name for the respective resource allows thesystem to obtain the respective resource from any device that stores acontent object with a hash value that matches the hash value included inthe hash-based name, thereby facilitating de-duplication of data in thedata model.
 6. The computer system of claim 1, wherein receiving thesecond manifest is further in response to the source device determiningthat a predetermined marginal threshold is reached and freezing the datamodel on the source device.
 7. The computer system of claim 1, whereinthe method further comprises: receiving a third manifest whichrepresents a final version of the data model, wherein the migrationphase indicated in the third manifest is a pull phase; and transmittinga third plurality of interests for the resources indicated in the thirdmanifest based on a name for a respective resource indicated in thethird manifest, wherein transmitting the third plurality of interests isbased on a policy of the system.
 8. The computer system of claim 1,wherein the method further comprises: transmitting a first interestwhich is a close checkpoint message with a name that indicates arespective manifest; in response to receiving an acknowledgment of thefirst interest, transmitting a second interest which is a confirmcheckpoint close message with a name that indicates the respectivemanifest; and receiving an acknowledgment of the second interest,wherein the source device releases the resources indicated in therespective manifest.
 9. A computer system for facilitating a migrationof a data model indicating resources, the system comprising: aprocessor; and a storage device storing instructions that when executedby the processor cause the processor to perform a method, the methodcomprising: generating a first manifest which represents a version ofthe data model, wherein a manifest indicates a phase of the migrationand a plurality of resources with corresponding names; in response toreceiving a first plurality of interests for the resources indicated inthe first manifest based on a name for a respective resource indicatedin the first manifest, transmitting a first plurality of correspondingcontent objects; in response to reaching a predetermined threshold:freezing the data model on the system; and generating a second manifest,wherein the migration phase indicated in the second manifest is astop-and-copy phase; and in response to receiving a second plurality ofinterests for the resources indicated in the second manifest based on aname for a respective resource indicated in the second manifest,transmitting a second plurality of corresponding content objects,thereby facilitating the migration of the data model over a contentcentric network from the system to a target device.
 10. The computersystem of claim 9, wherein generating the first manifest, receiving thefirst plurality of interests, and transmitting the first plurality ofcontent objects are in response to determining a pre-copy method for themigration of the data model, and wherein the migration phase indicatedin the first manifest is a push phase.
 11. The computer system of claim9, wherein the data model comprises an architecture for a virtualmachine, and wherein the resources are resources of the virtual machine.12. The computer system of claim 9, wherein a name is a hierarchicallystructured variable length identifier that includes contiguous namecomponents ordered from a most general level to a most specific level,wherein the name for a respective resource indicated in a manifest is ahash-based name which includes a hash value for data representing therespective resource, and wherein the hash-based name for the respectiveresource allows the target device to obtain the respective resource fromany device that stores a content object with a hash value that matchesthe hash value included in the hash-based name, thereby facilitatingde-duplication of data in the data model.
 13. The computer system ofclaim 9, wherein the method further comprises: generating one or morecheckpoint manifests, wherein a respective checkpoint manifest indicatesa unique version identifier for the data model, wherein the migrationphase indicated in the respective checkpoint manifest is a push phase,and wherein the second manifest represents a hot version of the datamodel.
 14. The computer system of claim 9, wherein the method furthercomprises: generating a third manifest which represents a final versionof the data model, wherein the migration phase of the third manifestindicates a pull phase; and in response to receiving a third pluralityof interests for the resources indicated in the third manifest based ona name for a respective resource indicated in the third manifest,transmitting a third plurality of corresponding content objects.
 15. Thecomputer system of claim 9, wherein the method further comprises: inresponse to receiving a first interest which is a close checkpointmessage with a name that indicates a respective manifest, transmittingan acknowledgment of the first interest; and in response to receiving asecond interest which is a confirm checkpoint close message with a namethat indicates the respective manifest: transmitting an acknowledgmentof the second interest; and releasing the resources indicated in therespective manifest.
 16. A computer-implemented method for facilitatinga migration of a data model indicating resources, the method comprising:generating, by a target device, a first interest for a first manifestwhich represents a version of the data model, wherein a manifestindicates a phase of the migration and a plurality of resources withcorresponding names; in response to receiving the first manifest,transmitting a first plurality of interests for the resources indicatedin the first manifest based on a name for a respective resourceindicated in the first manifest; receiving a second manifest, whereinthe migration phase indicated in the second manifest is a stop-and-copyphase; transmitting a second plurality of interests for the resourcesindicated in the second manifest based on a name for a respectiveresource indicated in the second manifest; and starting the data modelon the system based on content objects retrieved in response to thefirst and second plurality of interests, thereby facilitating themigration of the data model over a content centric network from a sourcedevice to the target device.
 17. The method of claim 16, whereingenerating the first interest, receiving the first manifest, andtransmitting the first plurality of interests are in response todetermining a pre-copy method for the migration of the data model,wherein the migration phase indicated in the first manifest is a pushphase, wherein receiving the second manifest is in response toretrieving content indicated in one or more checkpoint manifests,wherein a respective checkpoint manifest indicates a unique versionidentifier for the data model, wherein the migration phase indicated inthe respective checkpoint manifest is a push phase, and wherein thesecond manifest represents a hot version of the data model.
 18. Themethod of claim 16, wherein the data model comprises an architecture fora virtual machine, and wherein the resources are resources of thevirtual machine.
 19. The method of claim 16, wherein a name is ahierarchically structured variable length identifier that includescontiguous name components ordered from a most general level to a mostspecific level, wherein the name for a respective resource indicated ina manifest is a hash-based name which includes a hash value for datarepresenting the respective resource, and wherein the hash-based namefor the respective resource allows the system to obtain the respectiveresource from any device that stores a content object with a hash valuethat matches the hash value included in the hash-based name, therebyfacilitating de-duplication of data in the data model.
 20. The method ofclaim 16, further comprising: receiving a third manifest whichrepresents a final version of the data model, wherein the migrationphase indicated in the third manifest is a pull phase; and transmittinga third plurality of interests for the resources indicated in the thirdmanifest based on a name for a respective resource indicated in thethird manifest, wherein transmitting the third plurality of interests isbased on a policy of the target device.